1. Field of the Invention
This invention relates generally to an electronic commerce system and more particularly to delegating permissions in the system.
2. Background of the Invention
With the advent of electronic forms of communication, including telegraph, telephone, radio, television, and more recently digital networks, it has become possible to conduct commerce electronically using digital computer systems. Many electronic fund transfer systems require a xe2x80x9ctrustedxe2x80x9d third party between the vendor and consumer to authenticate the validity of the electronic funds. The requirement of a third party adds expense to every transaction because of the cost of extra communications and encryption. In addition, current electronic fund transfer networks, e.g., Western Union and Federal Reserve banks, typically require physically secure communications media which is immune to xe2x80x9ceavesdropping.xe2x80x9d Such secure networks are generally not available to consumers at large.
Alternative methods of electronic fund transactions involve establishing a long-term relationship between the vendor and consumer, either through a subscription service or by billing accounts as provided by credit card organizations. These methods are efficient at handling transaction requests, assuming a reasonable authentication scheme. However, these methods require a prior effort to establish an xe2x80x9caccountxe2x80x9d or other evidence of credit worthiness. For a large number of consumers, e.g. all potential users of a large network of computers like the Internet, setting up accounts and maintaining separate credit information with every vendor adds inconvenience and impediments to the consumers, and expense to the vendors.
In response to these needs, U.S. Pat. No. 5,802,497 (the ""497 patent) describes a lightweight and secure protocol for electronic commerce over the Internet. The protocol is designed to support purchases costing less than a cent. The system is based on decentralized validation of electronic cash at a vendor""s server without much additional communication, expensive encryption, or off-line processing.
Two innovations in the ""497 patent are its use of brokers and scrip. Brokers take care of account management, billing, connection maintenance, and establishing accounts with vendors. Scrip is digital cash that is valid for only a specific vendor. The vendor locally validates the scrip to prevent consumer fraud, such as double spending.
Every time a consumer visits a new vendor, the consumer must get scrip for that vendor from a broker. Scrip is held and manipulated by the consumer using an application called a xe2x80x9cwallet.xe2x80x9d The wallet includes scrip with each request to purchase content and gets back change from the vendor with the returned content. The consumer""s wallet may be stored and executed locally on the consumer""s computer system or it may run on a remote server.
Each piece of scrip has an associated customer secret. The consumer uses a hash including the customer secret to prove to the vendor that the consumer has the right to spend the scrip. Accordingly, the consumer""s wallet must remember and protect the customer secret. The consumer has complete control of the scrip and no one else can do anything with it, as long as the consumer keeps the customer secret confidential.
However, the consumer may wish to delegate the rights to perform specific actions with the scrip to one or more agents. For example, a consumer may be willing to trust a remote server to store its scrip, but the consumer may not be willing to give the remote server the right to spend the scrip. Yet, the consumer may want the server to refresh any scrip that is about to expire. Accordingly, there is a need for a way to delegate certain rights, permissions, and privileges to designated agents for specific pieces of scrip without revealing the full customer secrets.
The above needs are met by a method and system for electronic commerce that uses a delegation scrip secret (DSS) to enable the delegation of permission to perform certain actions to agents. The system includes a broker computer system having a database of broker scrip, each broker scrip representing a form of electronic currency. The system also includes a vendor computer system having a database containing products which may be exchanged for the vendor scrip, the vendor computer system capable of providing vendor scrip. In addition, the system includes a consumer computer system with which a consumer may initiate transactions to obtain one or more of the products contained in the database of the vendor computer system. The system also includes an agent computer system to which the consumer can delegate rights to perform certain actions on the scrip.
Each piece of scrip has a value, which, when it is a monetary value, may range from a few dollars to a few hundredths of a cent. In addition, each piece of scrip has a Customer ID from which a customer secret (CS) is derived. The broker and the vendor share and maintain a master customer secrets (MCS) table indexed by the Customer ID. When a broker (or vendor) issues scrip to the consumer, the broker hashes the Customer ID with the MCS specified in the table to form the CS. A preferred embodiment of the present invention uses the HMAC-MD5 algorithm for hashing when there is a distinguished value to use as the key, and the MD5 algorithm otherwise. The CS is sent to the consumer with the associated piece of scrip. The consumer holds the scrip and its associated CS in a database called a xe2x80x9cwalletxe2x80x9d and uses the CS to prove that the consumer has the right to spend the associated scrip.
A delegator, such as the consumer, delegates the rights to perform actions on scrip to a delegatee, such as an agent, by passing a list of the delegated actions to the delegatee along with the scrip. For sake of efficiency, the absence of any delegation represents the root delegation (i.e., the delegation of all rights). In addition, the delegation of certain actions may implicitly delegate other actions.
The delegator also preferably derives a delegation scrip secret (DSS) from the CS for the scrip. The DSS for the root delegation is the CS. For other delegations, the DSS is calculated as a hash of the new delegation with the old delegation scrip secret (i.e., the delegation secret owned by the delegator) as the key. The DSS is preferably securely transmitted to the delegates.
When the delegator and delegatee share access to the stored delegation (for instance, when it is stored in the scrip file for the wallet), the DSS""s must be encrypted by a method that both the delegator and delegatee can decrypt. Therefore, the delegator and delegatee must share a secret (called here the delegation pass phrase or DPP) for the encryption. Preferably, the delegator derives the DPP from the delegator""s own pass phrase and securely provides the delegatee with the DPP. In one embodiment, the DPP is calculated as a hash of the delegator""s pass phrase with the delegation and a nonce. With this embodiment, the delegator does not need to explicitly record the DPP for a delegatee. Alternatively, any agreed mechanism may be used to establish a shared DPP between the delegator and delegatee.
The delegatee may either directly remember and use the DPP provided by the delegator, or preferably may encrypt the DPP using a pass phrase of the delegatee""s choice and store it for eventual use.
Alternatively, the delegator and delegates may store the scrip separately. At the minimum, for each piece of scrip, the delegator stores its encrypted DSS and the nonce used to perform the encryption in its file. In addition, the delegator stores a delegation, encrypted DSS, nonce triple for each delegation of the scrip. Similarly, the delegatee stores the delegation, an encrypted DSS, and the nonce used to encrypt the DSS for each piece of scrip held by the delegatee and for each sub-delegation of the scrip.
To perform an action with a delegated piece of scrip, the delegatee sends a message to a server, such as a broker or vendor, containing the action, the scrip, the delegation, and a request stamp (RS). The RS is preferably formed from a hash of the action, scrip, and delegation concatenated together, with the DSS as the key. The server can determine the CS for the scrip, so the server is able to recreate the DSS and, thus, recreate the RS and validate the delegatee. If the delegatee validates, the server performs the requested action.
Typically, the server will respond to the delegatee with new scrip. For each piece of returned scrip, the server returns a new delegation for each delegation in the request, and a new delegation for each ancestor delegation in the delegation path of the incoming scrip (i.e., the scrip used in the request to the server). To avoid sending the delegation scrip secrets for the new delegations in the clear, the server preferably encrypts the returned secrets using a new DSS (NDSS) function. The NDSS is calculated using the delegation, the incoming scrip, the outgoing scrip, a nonce, and the DSS of the incoming scrip. The scrip, nonce, and delegation are returned to the delegatee with the new encrypted DSS. Since the delegatee already knows the old DSS for its delegations of the scrip used in the transaction, the delegatee can decrypt the new DSS for those delegations. If the delegatee does not know the DSS for a delegation of the scrip returned by the server, the delegatee stores the encrypted DSS in the scrip file in a xe2x80x9cdeferredxe2x80x9d format, along with information necessary to decrypt the DSS. When a party knowing the DSS for the scrip is activated, that party can then decrypt the deferred DSS.